Red Hat System Administration II 8.2

P1234567891011121314
Previous Next

Сброс пароля root

Задачи

После завершения этого раздела вы сможете войти в систему и изменить пароль root, если текущий пароль root был потерян.

Сброс пароля root из загрузчика

Одна из задач, которую должен уметь выполнять любой системный администратор, — сброс пароля root. Если администратор находится в системе как непривилегированный пользователь, но с полным доступом sudo, или как пользователь root, задача упрощается. Если администратор не в системе, ситуация немного сложнее.

Есть несколько способов задать новый пароль root. Например, системный администратор может загрузить систему, используя Live CD, смонтировать оттуда корневую файловую систему и отредактировать /etc/shadow. В этом разделе мы рассмотрим метод, который не требует применения внешних средств.

Примечание

В Red Hat Enterprise Linux 6 и более ранних версиях администраторы могут загрузить систему на уровне запуска 1, чтобы получить командную строку root. Ближайшим аналогом уровня запуска 1 на машине с Red Hat Enterprise Linux 8 являются цели rescue и emergency. Обеим требуется пароль root для входа в систему.

В Red Hat Enterprise Linux 8 можно сделать так, чтобы сценарии, которые запускаются из initramfs, приостанавливались в определенный момент, открывали сеанс командной оболочки с правами пользователя root, а после закрытия командной оболочки продолжали работу. В основном этот метод предназначен для отладки, но его можно использовать и для сброса пароля root.

Для доступа к командной оболочке root выполните следующие действия.

  1. Перезагрузите систему.

  2. Прервите обратный отсчет загрузчика, нажав любую клавишу, кроме Enter.

  3. Установите курсор на запись ядра, которое требуется загрузить.

  4. Нажмите e, чтобы отредактировать выбранную запись.

  5. Установите курсор на командную строку ядра (строку, которая начинается с linux).

  6. Добавьте rd.break. С этой опцией система приостанавливает работу перед передачей управления от initramfs фактической системе.

  7. Нажмите Ctrl+x, чтобы начать загрузку с учетом изменений.

В этот момент система открывает командную оболочку root, а фактическая корневая файловая система монтируется в режиме «только чтение» в /sysroot. Поскольку для устранения проблем часто требуется изменение корневой файловой системы, необходимо перевести ее в режим «чтение/запись». Далее показано, как опция remount,rw команды mount повторно монтирует файловую систему с новой опцией (rw).

Примечание

Готовые образы могут помещать несколько аргументов console= в ядро для поддержки различных сценариев реализации. Эти аргументы console= указывают устройства, которые будут использоваться для вывода на консоль. При использовании rd.break следует иметь в виду, что, хотя система отправляет сообщения ядра на все консоли, приглашение командной строки появится на консоли, указанной последней. Если приглашение не появляется, вы можете временно изменить порядок аргументов console= при редактировании командной строки ядра из загрузчика.

Важно

Система еще не включила SELinux, создаваемые вами файлы не имеют контекста SELinux. Некоторые утилиты (например, команда passwd) сначала создают временный файл, а затем заменяют им файл, который необходимо отредактировать, создавая новый файл без контекста SELinux. Поэтому, когда вы используете команду passwd с опцией rd.break, файл /etc/shadow не получает контекст SELinux.

С этого момента для сброса пароля root необходимо выполнить следующие шаги.

  1. Перемонтируйте /sysroot в режиме «чтение/запись». 

    switch_root:/# mount -o remount,rw /sysroot

  2. Переключитесь на chroot jail, где /sysroot используется как корень дерева файловой системы. 

    switch_root:/# chroot /sysroot

  3. Задайте новый пароль root. 

    sh-4.4# passwd root

  4. Убедитесь, что все файлы без меток (в том числе /etc/shadow) получают метки во время загрузки. 

    sh-4.4# touch /.autorelabel

  5. Дважды введите exit. Первая команда позволит выйти из chroot jail, а вторая — из оболочки отладки initramfs.

В этот момент система продолжит загрузку, выполнит переустановку меток SELinux, а затем снова перезагрузится.

Проверка log-файлов

Log-файлы с записями предыдущих неудачных загрузок могут оказаться очень полезны. Если системные журналы сохраняются при перезагрузке, вы можете использовать утилиту journalctl для просмотра log-файлов.

Помните, что по умолчанию системные журналы хранятся в каталоге /run/log/journal, а это означает, что они очищаются при перезагрузке системы. Для сохранения журналов в каталоге /var/log/journal, который не очищается при перезагрузке, задайте для параметра Storage значение persistent в файле /etc/systemd/journald.conf. 

[root@host ~]# vim /etc/systemd/journald.conf
...output omitted...
[Journal]
Storage=persistent
...output omitted...
[root@host ~]# systemctl restart systemd-journald.service

Для просмотра log-файлов предыдущей загрузки используйте команду journalctl с опцией -b. Опция -b без аргументов отображает только сообщения с момента последней загрузки. Если в качестве аргумента указано отрицательное число, отображаются сообщения предыдущих загрузок. 

[root@host ~]# journalctl -b -1 -p err

Эта команда отображает все сообщения, относящиеся к ошибкам или более серьезным проблемам в предыдущей загрузке.

Устранение проблем с загрузкой systemd

Для устранения проблем с запуском служб во время загрузки в Red Hat Enterprise Linux 8 можно использовать следующие методы.

Включение командной оболочки для отладки на раннем этапе

Если включить службу debug-shell с помощью команды systemctl enable debug-shell.service, система создает командную оболочку root на TTY9 (Ctrl+Alt+F9) на раннем этапе загрузки. Эта оболочка автоматически регистрируется в системе как root, поэтому администратор может выполнять отладку, пока операционная система загружается.

Предупреждение

Не забудьте отключить службу debug-shell.service по окончании отладки, иначе неаутентифицированная оболочка root останется открытой любому пользователю с локальным доступом к консоли.

Использование целей emergency и rescue

Если добавить systemd.unit=rescue.target или systemd.unit=emergency.target в командную строку ядра из загрузчика, система создаст восстановительную (rescue) или аварийную (emergency) оболочку вместо запуска в обычном режиме. Для обеих упомянутых оболочек требуется пароль root.

Цель emergency оставляет корневую файловую систему смонтированной в режиме «только чтение», а цель rescue ожидает, пока завершит работу sysinit.target, чтобы успели запуститься другие процессы системы, например служба журналов или файловые системы. Пользователь root не может вносить изменения в /etc/fstab, пока диск не будет перемонтирован с доступом на чтение и запись с помощью команды mount -o remount,rw /.

Администраторы могут использовать эти оболочки для устранения проблем, мешающих нормальной загрузке системы, например цикла зависимости между службами или неправильной записи в файле /etc/fstab. После выхода из этих оболочек будет продолжен стандартный процесс загрузки.

Идентификация зависших заданий

Во время запуска демон systemd порождает ряд заданий. Если какие-то задания не завершатся, это помешает выполнению других заданий. Администратор может использовать команду systemctl list-jobs для просмотра списка текущих заданий. Все задания, помеченные как running, должны быть выполнены, чтобы могло начаться выполнение заданий, помеченных как waiting.

Ссылки

Man-страницы dracut.cmdline(7), systemd-journald(8), journald.conf(5), journalctl(1) и systemctl(1)

Previous Next